As the dependence of society, economy, and living on an on-line service increases, the importance of identity management of managing information related to an individual or an organization is recently increasing. The identity management refers to a technique of increasing security and convenience of information related to an individual or an organization in various services or systems and managing an overall life cycle of an identity from registration to change and deletion.
Here, the identity is the totality of information specifying an individual, a group, an organization, or a company in a certain situation, and includes an identifier, a credential, and an attribute. The identifier is information identifying an identity, and corresponds to an account (a user ID), an employee number, or the like. The credential is information representing validity of certain information content, and includes a password or the like. The attribute is information characterizing an identity, and represents a name, an address, a date of birth, and the like.
As a representative example of a technique using an identity management technique, there is a single sign-on (hereinafter, referred to as an “SSO”). The SSO is a technique by which a plurality of applications or services can be used by a single authentication procedure.
There is a single sign-on as a technique of performing authentication collaboration capable of using a plurality of applications or services by a single authentication procedure. In the SSO, there are many cases in which authentications included in a plurality of applications are integrated in a single domain such as the Intranet of one company.
In addition, in recent years, the SSO is required between different domains (hereinafter, referred to as “cross domain”). The reasons may include an increase in corporate marriage or merge, overseas development, and the like, and an outsourcing by software as a service (SaaS) of raised cloud computing or the like.
However, in implementing the cross domain SSO, there is a problem in that a great deal of time and effort are required to share an authentication result. The main problems are the following two points.
A first problem lies in that since a use of an HTTP cookie is limited to a single domain, it is difficult to share an authentication result between domains using an HTTP cookie. A second problem lies in that since an SSO scheme of an access management product employed by each domain differs according to a vender, it is difficult to simply introduce, and it is necessary to prepare a separate measure.
In order to solve the above problems, there is a demand for standardization of an SSO among venders. As one of representative standard techniques to comply with a request, there is a security assertion markup language (SAML) made by an organization for the advancement of structured information standards (OASIS) which is a non-profitable organization.
The SAML is a specification that defines an expression form of information related to an authentication, an authorization, and an attribute and transmission and reception procedures, and is systematically specified so that an implementation can be made in various forms according to the purpose. Main entities include three of an identity provider (hereinafter, referred to as an “IDP” or “ID provider”), a service provider (hereinafter, referred to as an “SP” or “service provider”), and a user, and the SSO is implemented such that the service provider trusts in an authentication result issued by the ID provider.
When the SSO starts based on the SAML, it is generally necessary to prepare the following two points in advance. Firstly, a relation of trust needs to be constructed through information exchange or an agreement in a business or a technology between the service provider and the ID provider. Secondly, each user has an individual account for each service provider, and thus the individual SP account needs to collaborate with an account of the ID provider in advance (hereinafter, referred to as “account collaboration”). After advance preparation such as construction of the relation of trust and prior account collaboration is finished, the SSO can be performed.
After the advance preparation, the SSO is implemented by the following procedures (1) to (6). Here, an SSO procedure of a service provider-originated model using a user terminal will be described. In this procedure, basically, the process is performed in the ascending order unless otherwise set forth in.
(1) The user requests the service provider to provide a service.
(2) The service provider transmits an authentication request to the ID provider through a user side terminal since the user is not authenticated yet.
(3) The ID provider performs authentication on the user by a certain procedure, and generates an authentication assertion. The SAML does not specify an authentication means, and specifies only a system in which the authentication assertion is transmitted to the service provider. The authentication assertion includes information representing a way of generating the type of authentication means or a credential since the service provider determines whether or not the service provider can trust in an authentication result.
(4) The ID provider transmits the authentication result including the generated authentication assertion to the service provider through the user terminal.
(5) The service provider decides whether or not a service is to be provided based on the authentication result of the ID provider.
(6) The user is provided with a service from the service provider.
As described above, in the SSO based on the SAML, as the ID provider performs a single authentication procedure, the user can use a plurality of services without an additional authentication procedure. Currently, many venders are providing an access management product having IDP and SP functions of the SAML or a SaaS service having an SP function of the SAML.
However, the SSO based on the SAML is mere a part such as “use” of identity in an overall life cycle of an identity. As described above, when the SSO starts, it is necessary to perform account collaboration, and in order to perform account collaboration, a technique of comprehensively collaborating management such as registration, change, deletion, reissue, and temporary suspension of an identity between the service provider and the ID provider is required.
As a technique for automating registration, change, deletion, reissue, and temporary suspension of an identity, there is account provisioning, and as a standard technique thereof, there is a service provisioning markup language (SPML).
Meanwhile, there has been known a data processing system that actively executes account collaboration as a part of the SSO in a state in which the advance preparation of the account collaboration is not finished. Typically, when the SSO starts in a state in which the user's account is not registered to the service provider side, that is, in a state in which account collaboration is not performed, an error occurs.
However, according to this data processing system, the account collaboration can be actively executed as a part of the SSO even in the above-described state. Specifically, after the service provider receives a service request from the user, the service provider checks that information sufficient to register the user's account is not held. After checking, the service provider requests the ID provider to provide a user attribute, and the ID provider provides the service provider with a desired user attribute. As a result, the data processing system executes account registration and collaboration in the process of the SSO.
The above-described data processing system can request and provide the user attribute necessary for the individual user's account registration through a lightweight process, and has no problem in that a large quantity of preliminary process on many users is unnecessary.
However, according to the study of the present inventor(s), the following can be further improved.
Typically, when a company uses a service provided by the service provider, an information system (IS) section that controls an information system of a company in general performs account registration and collaboration on the service provider.
The IS section collectively performs account registration and collaboration on the user after a large quantity of preliminary process according to many users belonging to a company or after a procedure based on a series of authorization flow is performed at an arbitrary timing by the user.
Here, when the preliminary process of the former is performed, since account registration and collaboration need not to be executed in the process of the SSO, it is not related to the above-described data processing system.
Meanwhile, when the authorization flow of the latter is performed, a great deal of time and effort are required since a lot of manpower is necessary such as seniors, a procurement section, and an IS section of an organizational hierarchy to which the user belongs as well as the user. In addition, since the IS section does not collectively perform the preliminary process, a manual work is necessary, and a burden is great, and thus efficiency or convenience is bad. For example, it is difficult to have an advantage that it can be quickly used in the SaaS or the like.
Thus, in a system in which account registration and collaboration are executed in the process of the SSO, it is desirable to include a seamless system capable of deciding whether or not a service can be used without involving a manual operation.
In light of the foregoing, the present invention is directed to providing an authentication collaboration system, an ID provider device, and a program, which are low in the user's burden and capable of deciding whether or not a service can be used without involving a manual operation when account registration and collaboration are executed in the process of the SSO.